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ABSTRACT 

The past two decades have seen the rapid de- 
velopment of space astronomy, both manned 
and unmanned, and the concurrent proliferation 
of the operational concepts and software that 
have been produced to support each individual 
project. Having been involved in four of these 
missions since the '70's and three yet to fly in 
the present decade, the authors believe it is 
time to step back and evaluate this body of ex- 
perience from a macro-systems point of view to 
determine the potential for generic mission 
planning concepts that could be applied to fu- 
ture missions. This paper presents an organized 
evaluation of astronomy mission planning func- 
tions, functional flows, iteration cycles, replan- 
ning activities and the requirements that drive 
individual concepts to specific solutions. The 
conclusions drawn from this exercise are then 
used to propose a generic concept that could 
support multiple missions. 
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1. INTRODUCTION 

Recent trends toward subsystem commonality in 
astronomy spacecraft and the concurrent desire 
to drastically reduce ground system support 
costs set the stage for concomitant reductions in 
the resources required when developing new 
mission planning concepts. The time has come 
for a careful evaluation of astronomy missions 
flown during the last twenty years, including 
lessons learned, to determine the basic mission 
planning and scheduling functions and their 
commonality from mission to mission. A logical 
organization of the requirements for a generic 
astronomy mission planning system can and will 
materialize from this evaluation. The three 


main areas to analyze are: 1) mission planning 
functions, 2) functional flow considerations, and 
3) design drivers. After examining the three 
areas thoroughly, it becomes very simple to de- 
scribe the generic system and its core elements. 

A well-defined and implemented generic sys- 
tem will pay dividends by being able to support 
multiple satellites and by centralizing soft- 
ware maintenance and revisions. 

2. MISSION PLANNING FUNCTIONS 

The first step in this analytical approach is to 
look at each mission planning system (past, 
present, and future) and dissect it into its com- 
ponent functions. This process was done without 
regard for how the functions are packaged in 
software programs. The main generic functions 
that resulted from this analysis are described 
below. 

2.1 Observation and Engineering Request 
Processing 

The nature of astronomy mission planning requires 
a great deal of flexibility in receiving and pro- 
cessing observation requests. The astronomer us- 
ing the system must be able to easily submit, edit, 
and track requests until implementation. In like 
manner, engineering requests arising from space- 
craft health and safety considerations must also 
be developed by flight operations teams and en- 
tered into the scheduling stream where they can 
be merged with science requirements. This func- 
tion may also serve as an executive driver for the 
other functions. 

2.2 Orbital Mechanics 

Because orbital mechanics is the foundation on 
which an astronomy mission plan is built, the 
mission planner should have easy access to the 
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spacecraft ephemeris. The orbital mechanics 
function should be able, based on the 
ephemeris, to produce rise/set times for any 
point in the sky. Also, the mission planner will 
need to be able to calculate line-of-sight angles 
for the spacecraft and/or its pointings. These 
pointings are evaluated for compatibility with 
the spacecraft and instrument constraints. The 
orbital mechanics function must also be able to 
track other satellites. Sun, Moon, and planet 
positions, compute ground site and South 
Atlantic Anomaly (SAA) entry /exit times and 
earth occultation periods, and generate space- 
craft ground tracks. 

2.3 Guide Star Selection 

Once a target is chosen, the spacecraft will 
need to be given some guide stars near the target 
to fine tune the pointing angles and lock on the 
correct target. This can be done by the mission 
planners in a very straight-forward fashion. 
Software that incorporates the pointing algo- 
rithm of the telescope and the very latest star 
catalogs can be used to facilitate this task. The 
software should allow the user to easily ma- 
nipulate star tracker /aspect camera character- 
istics in case of a partial or complete sensor 
failure. Depending on mission-specific con- 
straints, the guide star selection function may 
run independently or in response to the schedul- 
ing function. 

2.4 Scheduling 

With observation and engineering requests and 
orbit mechanics data as inputs, the scheduling 
function produces and verifies an integrated 
spacecraft and viewing schedule. Past experi- 
ence suggests that this scheduler should be able 
to work in two modes, manual and automatic. 
For a generic system, scheduling constraints 
should be easy to create, edit, and decipher. 

The manual mode should employ graphics ca- 
pabilities using a mouse to insert and move ob- 
servations and other events throughout the 
schedule. The product of this function should be 
a mission schedule that is completely free of 
constraint violations. 

2.5 Editing 

Once a schedule is produced, the next task is to 
be able to edit it. This function is necessary be- 


cause mission schedules are usually generated 
weeks before execution, making them vulnera- 
ble to contingencies and significant ephemeris 
prediction errors. The editor should employ ex- 
tensive graphics using a mouse to drag events 
around on the screen. The editor will include 
ephemeris information and target position in- 
formation to calculate rise/set times as needed. 
Once a target is inserted into the schedule, it 
can be selected to show information about it at 
that time in the schedule. Since the editing 
function actually changes the schedule, it must 
also have a comprehensive validation capabil- 
ity to assure that the results maintain the 
schedule's integrity. 

2.6 Communications Planning 

Communications scheduling depends greatly on 
the interaction among spacecraft attitude and 
trajectory and satellite/ground site availabil- 
ity. For unmanned missions, communication op- 
portunities are determined 3-4 weeks ahead of 
time; however, on Space Shuttle missions, the 
schedule is more determined by spacecraft ori- 
entation rather than communication satellite 
availability. Either way, the mission planner 
must have a way of determining communication 
opportunities and be able to send contact re- 
quests to and receive schedules from the Space 
Network (SN) or the Deep Space Network 
(DSN). 

2.7 Spacecraft Management 

Following schedule development, the space- 
craft subsystem responses to execute scheduled 
events must be defined. Good design practice in 
modem astronomy satellites makes it more fea- 
sible to separate this increasingly independent 
function from the scheduling process. Events 
planned in the timeline, such as maneuvers and 
target pointings, dictate corresponding support 
from spacecraft appendages and subsystems. 
Solar array and high gain antenna movement 
and gimbal positions as well as data storage 
and communication device activities are in- 
cluded in this function. 

2.8 Flight Operations Team Support 

The mission planning and scheduling process by 
its very nature produces much information that 
is useful to flight operations teams. Typically, 
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this information is displayed on a large screen 
in a control center and/or fed to TV monitors and 
workstations to provide a focus or reference for 
mission operations. 

2.9 Command Management 

Although not a mission planning function per se, 
command management is included here for com- 
pleteness because in some projects it is combined 
with mission planning as a matter of conve- 
nience or as the result of organizational respon- 
sibilities. On Spacelab missions, it is not a part 
of the mission planning and scheduling system. 


MISSION PLANNING FUNCTIONS 

• Observation and Engineering 
Request Processing 

• Orbital Mechanics 

• Guide Star Selection 

• Scheduling 

• Editing 

• Communications Planning 

• Spacecraft Management 

• Flight Operations Team Support 

• Command Management (optional) 

Table 1. Mission Planning Functions 

3. FUNCTIONAL FLOW CONSIDERATIONS 

3.1 Modularity/Flexibility 

As a mission planning concept becomes more 
generic, its component functions must be more 
modular and flexible. This is particularly true 
of the orbit mechanics and scheduling functions, 
which must satisfy the biggest share of project 
requirements and constraints. Each astronomy 
mission flown in the past has had its own 
unique set of science observation requirements 
and spacecraft operations, and although there 
is a tendency now towards some commonality, 
new software and science instrument advances 
will in the future spawn new requirements and 
options unforeseen today. 

To posture itself for this onslaught of unknowns, 
the generic system must strive for a clean sepa- 
ration of the mission planning functions de- 
scribed above. Mission unique features can be 
modeled as input rules, algorithms and logic 
options in a scheduler with a standard user in- 
terface. Constraints that arise late in project 


development or due to flight contingencies can 
often be satisfied by clever manipulation of or- 
bit mechanics data. Functional modularity 
pays extra dividends by allowing standalone 
analysis Of special operational problems and by 
making it possible to easily reorder functional 
flows whenever mission experience or contin- 
gencies dictate a change in the mission planning 
functional flow process. 

3.2 Flow Sequence Optimization 

One of the most important considerations in 
mission planning concept design is the order in 
which individual functions are performed. 
Careful attention to the sequence of activities 
involved assures an efficient, smooth-flowing 
system and saves many hours of extra effort 
during mission operations. A poorly designed 
flow, on the other hand, will cause many unnec- 
essary iterations, confusion and added risk of 
error. For example, the checking of target visi- 
bility constraints after an observation has been 
scheduled instead of before is an open invita- 
tion to an endless iteration loop. The authors 
have noticed two errors in mission planning 
task flow that are common to many past and ex- 
isting systems. One of the most ubiquitous mis- 
takes is mixing orbital mechanics constraint 
calculations with scheduling algorithms in a 
minute-by-minute "sneak up on the limit" 
procedure. This approach is very repetitious 
and wasteful of computational resources. It is 
far more efficient to analytically solve for con- 
straints such as target rise/set times one time in 
the orbit mechanics function and feed this in- 
formation to the scheduling function. 

Another common mistake is the early computa- 
tion of spacecraft support events and commands 
in the scheduling process, long before they are 
actually needed. Combining these three inde- 
pendent functions creates a large amount of data 
that normally must sit around for several weeks 
before execution, making it vulnerable to con- 
tingencies and last minute changes. Changes to 
such volumes of data are labor-intensive and 
prone to error. 

This last point illustrates another strong con- 
sideration in flow sequence optimization. 
External planning cycles, such as TDRSS re- 
source scheduling, often dictate the generation 
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Figure 1. Generic Mission Planning Functional Flow 


of observation schedules several weeks before 
they are required by a control center. This fac- 
tor also leads to the conclusion that data 
should be generated when it is needed to mini- 
mize vulnerability and control center workload. 

In summary, the two most important mission 
planning flow optimization principles are (1) 
perform the functions in the most efficient order 
to minimize iterations and (2) generate the mis- 
sion planning products at the right time to min- 
imize editing workload. 

4. DESIGN DRIVERS 

4.1 Science Instrument and Spacecraft 
Complexity 

Fortunately, the major design drivers that af- 
fect astronomy mission planning concepts are 
relatively few (See Table 2). Of these, one of 
the most important is the complexity of science 
instrument and spacecraft design and the inter- 
action between them. The pickle-shaped 
fields-of-view of the Hubble Space Telescope 


(HST) Fine Guidance Sensors (FGS), for exam- 
ple, created a dependency among spacecraft at- 
titude, guide-star selection and seasonal varia- 
tions in target availability. Likewise, the dy- 
namic rate of data production from its science 
instruments, ranging from micro-seconds to 
hours, sometimes makes it necessary to make a 
trial run through the command management 
system to assure that on-board memory and/or 
uplink restrictions will not be violated by pro- 
jected observation schedules. 

4.2 Real-time Requirements 

Another closely related design driver is a re- 
quirement for real-time interaction with the 
spacecraft. This situation usually arises from 
the necessity to pinpoint faint object location 
and field orientations that are not well-known. 
To provide this capability, a link must be es- 
tablished between communication schedules 
done 3-4 weeks in advance and observation 
schedules. Last minute changes in planned con- 
tacts cause complex schedule interactions and 
require preplanned contingency procedures. 
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4.3 Manned vs. Unmanned 

Compared with unmanned operations the ad- 
vent of manned astronomy with the Astro-1 
mission brought a new set of problems that sig- 
nificantly affect mission planning system de- 
sign. Actually this design driver is composed of 
a number of different factors, but for purposes of 
this analysis they can all be attributed to hav- 
ing a "man in the loop." Two of these factors 
involved in Space Shuttle operations are the 
relatively short mission durations and frequent 
occurrences of launch delays, both of which dic- 
tate the independence of the orbital mechanics 
function, and the strong need for an efficient 
schedule editor and flexible scheduling soft- 
ware. 


DESIGN DRIVERS 

• Science Instrument and Spacecraft 
Complexity 

• Real-Time Requirements 

• Manned vs. Unmanned 

• Interfaces 

• Orbit Type 

Table 2. Design Drivers 

4.4 External Interfaces 

Although rarely the result of any definitive 
requirement, the external interfaces with a 
mission planning system often have a signifi- 
cant effect on shaping its design. Organiza- 
tional structure, roles and responsibilities, 
operational philosophies and the practi- 
calities associated with shared facilities play 
an important part in concept development. 
These factors are normally assumed rather 
than being explicitly derived. For example, an 
organization responsible for both spacecraft 
and science operations will typically merge 
these independent functions together for conve- 
nience. Also, scheduling and command man- 
agement are commonly combined if these re- 
sponsibilities reside under a common direc- 
torate. 

4.5 Orbit Types 

The last, but definitely not least, design driver 
is orbit type. Because of the more rapid pro- 
gression of environmental constraints, low earth 
orbit (LEO) missions are much more complex to 
plan than high earth orbit (HEO) missions. 


Similarly, highly elliptic orbits present more 
ephemerides prediction and timing problems 
than do circular orbits. 

5. CONCLUSIONS 

5.1 The Generic System 

After examining the component functions in- 
volved in a number of mission planning concepts, 
it appears that, if not one, at least a small 
number of generic systems are feasible. In fact, 
a first step towards a common concept might 
well be generic systems for certain types of mis- 
sions. If this approach is taken, the authors 
recommend dividing the systems by orbit type 
and manned/ unmanned operation. In any case, 
heavy emphasis should be placed on making 
the component functions as independent as pos- 
sible, so that they can later be linked into one 
generic system. The generic system proposed by 
the authors is illustrated in Figure 1. 

5.2 Core Elements 

The key to making the transition from these in- 
terim generic systems to one system is the iden- 
tification of "core" elements that change very 
little (or not at all) from mission to mission. 
Once these elements are standardized and used 
on several missions, the other elements can be 
examined one at a time to determine how they 
could be incorporated into the next-generation 
system. This close scrutiny will bring about new 
innovations in concept design and implementa- 
tion, eventually leading to one generic system. 
Even if it doesn't make sense to provide a func- 
tion that works for all missions, it is veiy pos- 
sible to hook alternatives into the system. A 
prime example might be a different scheduler 
for manned and unmanned missions. 

In like manner, functions and subfunctions not 
required for certain missions could be unplugged 
from the generic system. Spacelab missions, for 
example, don't need the spacecraft management 
element since the Shuttle Mission Control 
Center at Johnson Space Center performs this 
function. 

In any case, all space astronomy missions share 
much common ground in the planning activities 
that must be performed to implement observa- 
tion requirements. The time has come to exam- 
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ine these commonalities in search of a generic 
system to support future missions. 
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